
            <!DOCTYPE html>
            <html lang="en">
            <head>
                <meta charset="UTF-8">
                <title>Kuberntes云原生实战一 高可用部署架构</title>
            </head>
            <body>
            <a href="https://andyoung.blog.csdn.net">原作者博客</a>
            <div id="content_views" class="markdown_views prism-atom-one-light">
                    <svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
                        <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path>
                    </svg>
                    <h3><a id="Kubernets_0"></a><strong>Kubernets核心组件</strong></h3> 
<p>Kubernetes中组件众多，要完全介绍清楚估计要写上厚厚一本书，我们实战系列主要记住几个核心组件就行，即两种节点，三种IP，四种资源。</p> 
<h4><a id="_4"></a>两种节点</h4> 
<p>两种节点分别为控制平面master节点和工作节点worker节点，其中master节点中又有几个核心组件需要重点关注</p> 
<ul><li><strong>kube-apiserver</strong> ：提供了资源的增、删、改、查等操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制，所有worker节点只能通过apiserver与master节点交互；</li><li><strong>etcd</strong> ：分布式KV数据库 ，保存了整个集群的状态；</li><li><strong>kube-scheduler</strong> ：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；</li><li><strong>kube-controller-manager</strong>：负责维护集群的状态，资源对象的自动化控制中心，比如故障检测、自动扩展、滚动更新、服务帐户和令牌控制器等；</li></ul> 
<p>worker节点组件：</p> 
<ul><li><strong>kubelet</strong> : 负责Pod对应的容器的创建、启停等任务，与Master节点密切协作，实现集群管理的基本功能。</li><li><strong>kube-proxy</strong>：负责为Service提供cluster内部的服务发现和负载均衡；</li><li><strong>Container Runtime</strong> ：负责镜像管理以及Pod和容器的真正运行（CRI）</li></ul> 
<h4><a id="IP_19"></a>三种IP</h4> 
<p><strong>Node IP</strong> ：Node 节点IP地址，Node IP 是Kubernetes集群中每个节点的物理网卡的IP地址<br> <strong>Pod IP</strong> : Pod的IP地址 ，是一个虚拟二层网络<br> <strong>Cluster IP</strong>：Service的IP地址 ，也是一个虚拟IP。</p> 
<h4><a id="_25"></a>四种资源</h4> 
<table><thead><tr><th align="left">类别</th><th align="left">资源对象</th></tr></thead><tbody><tr><td align="left">资源对象</td><td align="left">Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、HorizontalPodAutoscaling</td></tr><tr><td align="left">配置对象</td><td align="left">Node、Namespace、Service、Secret、ConfigMap、Ingress、Label、 ServiceAccount</td></tr><tr><td align="left">存储对象</td><td align="left">Volume、Persistent Volume</td></tr><tr><td align="left">策略对象</td><td align="left">SecurityContext、ResourceQuota、LimitRange</td></tr></tbody></table> 
<p>虽然这里只说了核心组件，但是数量看起来并不少，一时半会要记住也不是容易事。不过没关系，咱们这里只需要记住有这么些东西即可，在上云实战篇还会反复提到，用着用着就记住了。</p> 
<p>接下来，我们看看Kubernetes的高可用架构。</p> 
<h3><a id="_40"></a><strong>高可用架构</strong></h3> 
<p>Kubernetes的高可用主要指的是控制平面（Master）的高可用，即指多套Master节点组件和Etcd组件，工作节点通过负载均衡器连接到各Master节点。</p> 
<p>HA通常有如下两种架构：</p> 
<p><strong>高可用架构一：etcd与Master节点组件混布在一起。</strong></p> 
<p><img src="https://i-blog.csdnimg.cn/blog_migrate/d47c69d85faccf036abbffdf359c2b9a.png" alt="图片"></p> 
<p><strong>高可用架构二：使用独立的Etcd集群，不与Master节点混布。</strong></p> 
<p><img src="https://i-blog.csdnimg.cn/blog_migrate/aaca72da12e02af63aeec8acdead9bf8.png" alt="图片"></p> 
<p>两种方式的相同之处在于都提供了控制平面的冗余，实现了集群高可以用，区别在于：</p> 
<ul><li>Etcd混布方式</li></ul> 
<ol><li>所需机器资源少</li><li>部署简单，利于管理</li><li>容易进行横向扩展</li><li>风险大，一台宿主机挂了，master和etcd就都少了一套，集群冗余度受到的影响比较大。</li></ol> 
<ul><li>Etcd独立部署方式：</li></ul> 
<ol><li>所需机器资源多（按照Etcd集群的奇数原则，这种拓扑的集群关控制平面最少需要6台宿主机了）</li><li>部署相对复杂，要独立管理etcd集群和和master集群</li><li>解耦了控制平面和Etcd，集群风险小健壮性强，单独挂了一台master或etcd对集群的影响很小</li></ol> 
<p><strong>提示：我们使用高可用架构一 实现Kubernetes的高可用。</strong></p> 
<blockquote> 
 <p>这里需要特别说明一下，Scheduler 和 Controller-manager 虽然在Master中部署了多个节点，但同时工作的节点只有一个，因为Scheduler 和 Controller-manager属于有状态服务，为了防止重复调度，多个节点的Scheduler 和 Controller-manager进行了选主工作，工作节点信息保存在Scheduler 和 Controller-manager的EndPoint中，可通过<code>kubectl get leases -n kube-system</code>查看。</p> 
</blockquote> 
<h4><a id="_73"></a>负载均衡器</h4> 
<p>不管是方案一还是方案二，都需要一个负载均衡器，负载均衡器可以使用软件负载均衡器Nginx/LVS/HAProxy+KeepAlibed或硬件负载均衡器F5等，通过负载均衡器对Kube-APIServer 提供的VIP即可实现Master节点的高可用，其他组件通过该VIP链接Kube-APIServer。</p> 
<p>这里我们选用的是 HAProxy+KeepAlibed 构建的负载均衡器。</p> 
<p>最终的部署架构图如下：</p> 
<p><img src="https://i-blog.csdnimg.cn/blog_migrate/56d74ca8368ab27960c17a7499ac2ffa.png" alt="图片"></p> 
<blockquote> 
 <p>架构说明</p> 
 <ol><li>etcd跟master节点部署在一起，依靠master节点实现高可用</li><li>通过keepalived和haproxy实现apiServer的高可用</li></ol> 
</blockquote> 
<p>有了上述的部署架构，接下来我们就可以规划机器了。</p> 
<h3><a id="_90"></a><strong>机器规划</strong></h3> 
<table><thead><tr><th align="left">主机名</th><th align="left">IP地址</th><th align="left">配置（CPU-内存-硬盘）</th><th align="left">系统版本</th><th align="left">说明</th></tr></thead><tbody><tr><td align="left">k8s-slb1</td><td align="left">172.30.15.***</td><td align="left">2C-4G-50G</td><td align="left">Centos7.8</td><td align="left">Keepalived &amp; HAProxy</td></tr><tr><td align="left">k8s-slb2</td><td align="left">172.30.15.***</td><td align="left">2C-4G-50G</td><td align="left">Centos7.8</td><td align="left"></td></tr><tr><td align="left">k8s-master1</td><td align="left">172.30.15.***</td><td align="left">8C-32G-150G</td><td align="left">Centos7.8</td><td align="left">master+etcd</td></tr><tr><td align="left">k8s-master2</td><td align="left">172.30.15.***</td><td align="left">8C-32G-150G</td><td align="left">Centos7.8</td><td align="left"></td></tr><tr><td align="left">k8s-master3</td><td align="left">172.30.15.***</td><td align="left">8C-32G-150G</td><td align="left">Centos7.8</td><td align="left"></td></tr><tr><td align="left">k8s-worker1</td><td align="left">172.30.15.***</td><td align="left">8C-32G-500G</td><td align="left">Centos7.8</td><td align="left">CICD + 存储</td></tr><tr><td align="left">k8s-worker2</td><td align="left">172.30.15.***</td><td align="left">8C-32G-500G</td><td align="left">Centos7.8</td><td align="left"></td></tr><tr><td align="left">k8s-worker3</td><td align="left">172.30.15.***</td><td align="left">8C-32G-500G</td><td align="left">Centos7.8</td><td align="left"></td></tr></tbody></table> 
<p><strong>说明：由于有些应用或中间件有持久化数据的需求，上表中也将存储考虑进去了，跟worker节点放在一起，后面会单独讲存储。</strong></p> 
<p>看到这里不要紧张，觉得一下子需要用这么多机器，等你的应用上云以后这些机器完全是可以节省下来的。</p> 
<h3><a id="_107"></a><strong>框架选型</strong></h3> 
<p>接下来我们看看整体的框架选型，包含容器平台、存储、Kubernetes搭建工具。</p> 
<blockquote> 
 <p>前期我们做技术选型的时候花了很多精力来调研，调研过程就不展示了，直接放结论。</p> 
</blockquote> 
<h4><a id="_113"></a>容器平台</h4> 
<table><thead><tr><th align="left">容器平台方案</th><th align="left">优点</th><th align="left">缺点</th><th align="left">说明</th></tr></thead><tbody><tr><td align="left">KubeSphere</td><td align="left">代码全开源、社区活跃、UI 体验 较好、背后是青云上市公司团队支持</td><td align="left">多集群管理不完善 使用过程中还是有些小bug</td><td align="left">学习材料有视频+文档形式，适合团队快速学习上手，同时官方有固定的双周会，可以参与了解项目发展情况</td></tr><tr><td align="left">Kuboard</td><td align="left">相关文档较较细致、可以作为学 习材料使用</td><td align="left">个人开源项目， 文档开 源，代码不开源</td><td align="left">文档写的较全，适合通过该项目 初步了解 k8s，是一个不错的搭 建 k8s 的学习材料平台， 不建议生产使用。</td></tr><tr><td align="left">Rancher</td><td align="left">开发团队强大、社区活跃、强项 整合云平台资源、老外公司</td><td align="left">文档英文为主、WebUI 使用起来总有种卡顿的 感觉</td><td align="left">国内有部分公司在用，主要反馈产品体验不好，技术团队实力较强，中文文档滞后。</td></tr></tbody></table> 
<p>入选者：KubeSphere</p> 
<p>选型理由： 安装简单，使用简单</p> 
<ul><li>具备构建一站式企业级的 DevOps 架构与可视化运维能力 (省去自己用开源工具手工搭建积木)</li><li>提供从平台到应用维度的日志、监控、事件、审计、告警与通知，实现集中式与多租户 隔离的可观测性</li><li>简化应用的持续集成、测试、审核、发布、升级与弹性扩缩容</li><li>为云原生应用提供基于微服务的灰度发布、流量管理、网络拓扑与追踪 提供易用的界面命令终端与图形化操作面板，满足不同使用习惯的运维人员</li><li>可轻松解耦，避免厂商绑定</li></ul> 
<h4><a id="_131"></a>存储选型</h4> 
<p>这里只考虑了分布式的存储组件，如本地存储OpenEBS我们直接pass了。</p> 
<table><thead><tr><th align="left">存储方案</th><th align="left">优点</th><th align="left">缺点</th><th align="left">说明</th></tr></thead><tbody><tr><td align="left">Ceph</td><td align="left">资源多，大多容器平台都有支持 Ceph。</td><td align="left">运维成本较高，都说没有 Ceph 集群故障处理能 力，最好不要碰</td><td align="left">曾经，经历过 3 副本全部损坏 数据丢失的惨痛经历，因此没有能力处理各种故障之前不会再 轻易选择（来源于社区人员的反馈）.</td></tr><tr><td align="left">GlusterFS</td><td align="left">部署维护简单、多副本高可用</td><td align="left">资料相对较少；很久都不更新升级了</td><td align="left">部署和维护简单，出了问题找回数据的可能性大一些</td></tr><tr><td align="left">NFS</td><td align="left">使用广泛</td><td align="left">单点网络抖动</td><td align="left">不建议您在生产环境中使用 NFS 存 储 （ 尤 其 是 在 Kubernetes 1.20 或 以 上 版 本）， 这可能会引起 failed to obtain lock 和 input/output error 等 问 题 ， 从 而 导 致 Pod CrashLoopBackOff 。此 外，部分应用不兼容 NFS，例 如 Prometheus 等</td></tr></tbody></table> 
<p>入选者：Ceph</p> 
<p>选型理由：</p> 
<ol><li>可以通过ROOK快速构建Ceph高可用集群，使用者众多</li><li>支持多种存储类型，块存储、文件存储、对象存储，非常方便</li></ol> 
<h4><a id="K8S_148"></a>K8S搭建工具</h4> 
<table><thead><tr><th align="left">存储方案</th><th align="left">优点</th><th align="left">缺点</th></tr></thead><tbody><tr><td align="left">Kubeadm</td><td align="left">K8s 官方推荐的集群搭建工具</td><td align="left">需要手动续期 k8s 集 群证书</td></tr><tr><td align="left">Kubekey</td><td align="left">在更方便、快速、高效和灵活地安 装 Kubernetes 与 KubeSphere。支持单独 Kubernetes 或整体安 装 KubeSphere。自动续期 k8s 集 群证书</td><td align="left">不是 k8s 官方工具</td></tr><tr><td align="left">二进制安装</td><td align="left">满足个人学习需要</td><td align="left">部署复杂</td></tr></tbody></table> 
<p>入选者：Kubekey</p> 
<p>选型理由：</p> 
<p>简单易用，是在 kubeadm 基础上诞生的工具，主要看重 k8s 集群证书自动续期功能，不用运维到期前手动续期。该工具虽然不是 k8s 官方提供的工具，但是是通过 CNCF 验证的工具，CNCF kubernetes conformance verification。</p> 
<h3><a id="_162"></a><strong>软件版本</strong></h3> 
<table><thead><tr><th align="left">软件名称</th><th align="left">软件版本</th><th align="left">说明</th></tr></thead><tbody><tr><td align="left">操作系统</td><td align="left">centos7.8</td><td align="left">注意操作系统内核 3.10 内核在大规模集群具有不 稳定性，内核升级到 4.19+ # 查看内核版本 uname -sr 目前以 3.10</td></tr><tr><td align="left">KubeSphere</td><td align="left">3.2.1</td><td align="left">截止发文时最新版本</td></tr><tr><td align="left">Kubekey</td><td align="left">v2.0.0</td><td align="left">截止发文时最新版本</td></tr><tr><td align="left">Docker</td><td align="left">20.10.9</td><td align="left">求稳</td></tr><tr><td align="left">Kubernetes</td><td align="left">1.21.5</td><td align="left">Kubekey2.0.0支持的最高版本</td></tr></tbody></table> 
<h3><a id="_172"></a><strong>小结</strong></h3> 
<p>今天主要简单介绍了一下Kubernetes的核心组件和Kubernetes高可用部署方案以及相关技术选型。Kubernetes很难，要学会Kubernetes完全通过看书是不现实的，必须要反复实践，有条件的同学建议跟着本系列课程实操一遍。</p>
                </div>
            </body>
            </html>
            